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ACCESS MAMAGEMENT SYSTEM AND METHOD 
EMPLOYING SECURE CREDENTIALS 



Technical Field 



The invention relates to information security, and more particularly, to systems and method for 
improving the security of mformation transactions over networks. 

Backprounrl Art 

The internet has become an important medium for information services and e.ectronic commerce As 
the internet has been cornmerc.alized, organizations initia.ly established the, presence m cyberspace by 
ltlf0rmatI ° n (tyP1C3lly StatlC ' P^ottona. information) available on resources well 

removed from the operational uifrastmcture of the organization. Secur.ty issues were often addressed by 
•so lating pubhc.y accessible resources (e.g., web servers) from more sensitive assets using firewall techmoues 
As .ong as the publicly accessible information and resources were relatively non-sensitive and user 
interactions with such information and resources was no, m.ss.on critical, relatively simp.e fu-ewa.l techniques 
were adequate. Though information and resources outside the firewall were at risk, the risk cou,d generally be 
hrmted to non-proprietary information that was easily replaceable ,f compromised. Proprietary .formation 
and systems critical to day-to-day operations were sheltered behind the firewall and information flows across 
the firewall were filtered to exclude all but the comparative.y non-threatening services such as electronic ma„ 

However, as the internet has become more pervasive, and as the sophistication of tools and techniques 
has increased, several aspects of the secunty environment have changed dramatically. First, businesses have 
recognized the power of information transactions that more tightly coup.e to operation, data systems, such as 
order processing, inventory, payment systems, etc. Such transacts include electronic commerce with direct 
purchasers or consumers (e.g., browsing, selecting and purchasing of books by members of the pub.tc from an 
on-hne bookseller) as we., as supply chain and/or business partner interactions (e.g., automated just-in-time 
inventory management, customer-specific pricing, availability and order status information etc ) 
Commercially relevant transactions increasingly require information flows to and from secure operational 
systems. Second, even information-only services are increasing mission-critical to the* providers 
Corporate image can be adversely affected by unavailability of, or degradation access to, otherwise uon- 
sensmve information such as customer support information, product upgrades, or marketing and product 
.formation. Because many businesses re.y heavily on such fachties, both unauthonzed modification and 
denial of service represent an increasing threat. 

Individual info™,™ setvi ce or .rahsac.iou sysKra w , cal|y M ^ 
While .s possible ,o field u,d,v,dua,,zed securiiy sc ,,u,i 0 „ s for each information serv.ee o, bansaCon 
system, individualized solurions make i, difficult ,o mamuin a uniform secur i(y policy across , se, of 
applicaunns o, resources. Furmermore, individualized sol„,i„„s rend ■„ fosrer ipcompadWe securiry islands 
w,,h,„ wha, would .deaUy be pr.semed ,„ consumers or business parbrers as a Single, m.egra.ed emerpnse 
For example, a user ,ha. has already been au,ben,ica,ed for access ,o an order processing sys.em may 
unnecessarily be re-,„,he„,,ca,ed when accessing ,„ order siarus sysiem Worse s,i„, a se, of individua.ized 
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compromised through a low security entry point. 

A "; her •* ww-i-d S o, u „„ ns is . v „, table e , pl0Slon ,„ the number 

conb* c„„ frommg . user . As mo „ and mofe busmess . ^^^^ 
5 eo^„,e d wiIh multlple ldcm , fiers a „ d passwords fw vanoys sys[ems ^ • 

«* *« U » rs . A s Ae w erows , o mc|ude vendQrs cus|ome 

and odle „ ,„ add „, on , 0 emp|oyees a huge facej ^ 2, 0 „ „ 

— „ scrs are , hemse|v „ confromed m , h |arge numbers ^ ^ d ™„ . 

::i:rzr? po,,ciessuchaspasswordrcs, ' k '' o " sa " d - ui — 

«~ »^»». eobnstcess ,„ d.«^ or ea s„ y . ascmamal> , e mfomadon atack 

™ be reduced A! users acqu ,„ more passwords _ somc , ndiv , dua|s m>y M ^ J P J- - > 
he,p bu, „ r „e dow „ „, creale easy ., 0 . temember a „ d easy ., o . c0mpromiM passwords 

DISCLOST.RF ott INVENTION 

Session clr°Tr' y ' ' S " Ur '^ de " e ' OPed •«* ' **• U P-ded. 

more .nrc™,,™ „ sourc «, a „ d ,„ some ^ « 

z i rrr a r ,o ver,fv an au,hem,cai " ^ " v "- » ^ - - - 

exeep, by . ^ d authe „ tlcadon .. se „ ice . Some embodjmenis of ^ p[estn| ^ 

^— — _. AulhCTllcalio „ schemes (e g lhose based on 

w„„ p „. For examp , c m one configura(ion> a - 

™es> ,„ be accessed a „ d wlth envlrorm]em ^ ^ ^ 

*pe Once ,c,,„ cedents bsve been „b ai „e d f „ a „ „ dty a „ d have b „„ ^ 

^e,. sess,o„ c red e„, ials are 1S s U e d and acC ess ,s gra „,e d ,„ mf _ „ fe which J J ^ 

^T* - -* 1 "^-™^-~.onc r e d e» U a 1 sev, d e„cn lgaJ „ nsu C 
m« ,eve, may be r e m e d ,e d by . sess.on c„„„„„ lty preservulg upgrade or|og , n 

.n one emboOnnen, ,„ accordance wdh fc ^ § ^ 

i r ; : , " ,hen " ca,,on ora iosm ~ ,o - >™*« * -4- 

I : I" IOei " Crede "" alS °"' «" »— «*- « -PP-ed e„e mal ,„ fc 

security arch.tecture as a session token. 
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^ in another embodtmen, a accordance with fc g ^ ^ ^ 

• d« operattng on behalf of a prmcipa| a „ d . sccufiry ^ 

™ ^7"^°^ 10 ~ * .de„,r, er and authorKatl0n , evc , mdlcallon „ e 

access ,„ the ,„f„rma,,„„ resource without re-amhenttcation of the logo, credentials 

In s,„, another embod.men, ,„ accordance Witt, Ore pteseo, „„,„, , me[nod orprov 

'ZZZTT " T"* arch,,ecmre conMllmg access - °™ - — — ~ 

S ° bta,mng * '° 8m Credt "" al a " d ng a principal .hereby and ,ssu,„g a c w ,og,apnica„ y 

-cored scs.on credent, ^ olographic,,,, secnred sess.on credenna, encodes a, Jan do I for 
he pnocpa, and a firs, anttmrizanon accorded based on the a „tt, e „ Uca , mg . For p , ura , „ quesK for * 
7 m ;7 ,ht inf — — • «" — -ber ,„c,ude s se,ec,,e, y allowmg ac l b d 
17"' °" b ":' S — ^ - <~nica„ y secured sess.on creden ,a, f „r a c , 

::::::;:::i;:r^ 

^ If :::':;r: r a::z::— rrrrr-^-- 

p™ y is for rece.vtng an access ,e q ues, targ „„g one o Z , Z ^ "'^ ^ aPP "" U °" 

4 ar g etIn g of the information resources, extracting a 
cryptographically secured sess.on token from the access request and selective u 
^ans — — 

cr y p 1 ogr a ph,ca„ y secured sess.on token for access ,„ the targeted inform,,™ resource. 

BRIEF DESCRIPTION o r DRA WINfJo 

The presen, invention m ay be better unders.ood. and i, s numerous objects, features, and advances 
made apparent ,o those skilled in ihe an b y referencing the accompan y ,„g drawtngs. 

FIG. I biock d.agratn fluffing information „ ows betw „„ ^ ^ 

arcWcure em pl „ y ,„g secure session credent.als on accordance wt.h an cemplarv embod.men, of doe preseo, 

PIG. 2 is a flow chan illosrrafing operahon of, secuntv architecture emp,„ yi „g S e C „ r e sesston 
credentials .„ accordance with an cemplarv embodnoen, of the present invention. 

FIG 3 illustrates tnteractions between functional components ,„ a functional decomposition of a 



PCTYUS00/20931 



FIG. 4 illustrates relations between login credentials, session credentials and a cookie encoding of a 
session token in accordance with an exemplary embodiment of the present invention. 

The use of the same reference symbols in different drawings indicates similar or identical items. 
MODE(S) FOR CARRYING OUT THE rNVFNTION 

Some terminology used in this specification has mean.ng particular to the context of embodiments 
described herein. Therefore, to aid persons of ordinary skill in the an in understand.ng the full scope of the 
invention, some of that terminology is now defined. 

Glossary 

Access Management: Systems, methods and techniques for controlling use of information resources. 
Typically, access management systems employ both authentication and authorization to control access to 
information r 



Authentication. A process used to verify the identity of an entity. As typically implemented, an 
authentication method is employed to verify the identity of a user or object based on a credential supplied by 
the user or object 

Authorization: A process for determining whether an identity is permitted to perform some action, 
such as accessing a resource. Typically, an identity will be authenticated, though in some configurations 
certain identities need not be. 

Credential: Evidence of identity used to authenticate an entity. Exemplary credentials types include 
passwords, certificates or other encrypted indicia based on asymmetric, symmetric, public, private, or secret 
key technologies, one-time passwords, biometric indicia such as by retinal scan, voice print, finger print, etc., 
and possession based indicia such as smart cards, Enigma cards, keys, etc. In some realizations, credentials 
may be associated with users, sessions, functional objects, etc. 

Digital Signature: A transformation of a message using an asymmetric cryptosystem such that a 
person having the initial message and the signer's public key can accurately determine whether the 
transformation was created using the private key that corresponds to the signer's public key and whether the 
message has been altered since the transformation was made. 

Entity: A user or object, including data objects and/or functional objects such as applications, 
components, modules, services, processes, threads, etc., as well as instantiations thereof. In some 
configurations, only user entities (typically, the human principal interacting with a software program or on 
whose behalf a software agent purports to act) are considered. In other configurations, entities include 
functional objects without an associated human principal. The identity of an entity may be authenticated using 
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Session: A period and collection of states spanning one or more interactions between an entity and an 
information environment. As used herein a session may span multiple interactions with multiple resources of 
the information environment and, in some configurations, may span multiple information access protocols 
(e.g., HTTP, FTP, telnet, etc.). A session has a beginning and an end. During its existence, a session has state. 
5 As used herein, the term session connotes a greater persistence than as sometimes used to describe the period 
of a "session layer" protocol interaction, which in the case of some protocols, such as HTTP, is generally very 
short-lived 

Single Sign-on Security Architecture 

FIG. 1 provides an overview of major interactions between components for an exemplary security 
10 architecture in accordance with the present invention. As illustrated in FIG. 1, a client application, e.g., a 
browser 170 operated by a user, interacts with the security architecture via a gatekeeper and entry handler 
component 110 and a login component 120. Gatekeeper and entry handler component 1 10 provides an entry 
point for external client applications requesting access to enterprise applications and/or resources, including 
e.g., information resources 191, 192 .. 193, for which access management is provided by the security 
15 architecture. Using facilities provided by a session management component 160, an authorization component 
140, an authentication component 130, an identification component 150, and login component 120, the 
gatekeeper/entry handler component 110 allows, redirects or refuses access requests in accordance with a 
security policy. 

Individual information resources typically have differing security requirements. In addition, 
20 individual types of access to a single information resource may have differing security requirements. 

Nonetheless, a given level of security may be sufficient for more than one of the information services or access 
types. For example, information resource 191 may include a product information service for providing general 
information such as product descriptions or data sheets to the public, while information resource 192 includes 
an order processing system for an eCommerce site. Information resource 193 may include functions for 
25 supply chain interactions such as access to inventory information or current selling price information. Both 
the product information service and order intake functions of the eCommerce may operate with similar 
security requirements, e.g., allowing access by minimally authenticated, non-hostile entities. On the other 
hand, supply chain functions may require a higher level of security. Order status functions of the order 
processing system may require a mid-level of security. 

30 Lo gi n component 120, operating tn conjunction with gatekeeper/entry handler component 110 and 

other components of the security architecture, provides a single sign-on interface for access to enterprise 
applications and/or resources In an exemplary embodiment, security requirements are expressed in terms of 
trust levels and login component 120 obtains login credentials for an entity requesting access to one of the 
enterprise applications and/or resources. The login credentials obtained are selected from a set of credential 

35 types that, if authenticated, are sufficient to achieve the trust level requirement of an application or information 
resource to be accessed. Without limitation, typical login credential types and associated authentication 
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mechanisms include those based on passwords, certificates, biometric techniques, smart cards, etc Other 
credential types and associated authentication mechanisms are described elsewhere herein. 

In some embodiments in accordance with the present invention, gatekeeper/entry handler component 
1 10 queries authorization component 140 to obtain authorization for access to a particular requested enterprise 
application or information resource by the requesting entity (e.g., the browser user). If the entity requesting 
access has not yet been authenticated to the trust level required for the particular access to the particular 
enterprise application or information resource requested, authorization component 140 may indicate that the 
access request is to be red.rected to login component 120 so that login credentials may be obtained and 
authenticated to a particular trust level. If, on the other hand, login credentials have already been obtained for 
the requesting entity and the requesting entity has been authenticated using the obtained credentials such that 
the required trust level has been achieved, the access will typically be allowed without the need for further 
login credentials and authentication. In certain circumstances, authorization component 140 may indicate that 
the access is to be refused. For example, authorization component 140 may be programmed to perform more 
stringent testing beyond a trust level requirement. In an exemplary enterprise tool configuration, a desired 
security policy may dictate that a salary tool is accessible only from with a company's internal network. No 
level of authenticated trust may be sufficient to access such a tool from outside company network. To 
facilitate implementation of such a security policy, authorization component 140 could refuse access based on 
environment parameters indicating a session originating outside the company's interna! network 

Of note, in certain embodiments in accordance with the present invention, the mapping of login 
credential types and authentication mechanisms to trust levels is influenced by environment information such 
as time of request, source of request, connection speed, and/or client application (e.g., browser) environment 
information. In this way, even with a static set of mapping rules, the set of credential types and authentication 
mechanisms suitable to support a given trust level may vary based on environment information. In general, 
mapping rule dependencies are based on perceived variations in threat characteristics and/or requesting entity 
capabilities. In some embodiments in accordance with the present invention, gatekeeper/entry handler 
component 110 is the authority on environment information for a particular requesting entity. 

In some embodiments, mapping rules may be dynamically varied. For example, if a particular login 
credential type and/or authentication method is deemed insecure (e.g., because compromised or because of a 
changing threat profile), the trust level mappings can be updated and have enterprise-wide effect. In addition, 
several other advantages are achieved by defining the authentication requirement interface between enterprise 
applications and/or resources and the security architecture in terms of required trust levels, rather than in terms 
of particular credential types and authentication methods. First, single sign-on configurations are facilitated 
using an enterprise-wide credential obtaining, authentication and session tracking infrastructure. Second, 
authentication requirements may be enforced uniformly in accordance with an enterprise-w.de security policy 
and with reduced vulnerability to a lax security implementation by any particular information resource. Third, 
credential types and authentication methods can be added, deleted, or mapped to a new trust level, all without 
modification ofenterpr.se applications and resources. Of course, all advantages need not be achieved in any 
particular implementation. 
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In certain embodiments in accordance with the present invention, a credential upgrade facility is 
provided. In response to an access request from an entity for wh.ch login credentials have already been 
obtained and authenticated, but for wh.ch the obtained and authenticated login credentials are insufficient for 
the trust .eve. associated with the requested access, authorization component 140 may indicate that the access 
request rs to be redirected to login component 120 so that sufficient login credentia.s may be obtained and 
authenncated to the required trust level. Of note, credential upgrade facilities in accordance w.th certain 
embodiments of the present invention allow upgrade without loss of session continuity. 

In addition to the obtained logm credentials, some configurations in accordance with the present 
tnvention employ session credentials as a mechanism for evidencing pr.or authentication of obtained login 
credentials and for binding individual transactions to a particular session. In some configurations sess.on 
credent.als are also employed in a session token form advantageous for transactions external to the security 
architecture. In an exemplary realization, session tokens are encoded for supply to browsers as cookies 
FIG. 4 illustrates relationships between exemplary login credential, session credential and session token 
objects 

As described above, login credentials (e.g., represented in a form such as exemplary login credentials 
stmcture 410) are obtained for a chent entity. Typ.cally, , og m credentials encoded in login credentials 
structure 410 are obtained from a principal via browser client and serve as evidence that the principal (e g a 
human user) ,s entitled to a part.cular .dent.ty. Accordingly, login credentials structure 410 encodes a userld 
and a domainld within which the userld should uniquely correspond to a principal. Specific login credentials 
e.g., a password, a certificate, results of a b.ometnc process, a response to an Enigma challenge or results of a 
smart card interrogation, etc. are encoded in login credentials structure 410, as a tagged value. An 
authenticationScheme is specified and creation time may be encoded to limit replay attacks In the 
implementation of FIG. 4, login credentials structure 410 is encrypted using the publ.c key of an 
authentication service (e.g., of authentication component 130). Because the key is public, any component, 
even untrusted components may encrypt login credentials for provision to authentication component 130 
while only authentication component can decrypt the encrypted login credentials using its private key In * 
some configurations, secure transfer protocols, e.g., SSL, are employed to secure login credentials between a 
client entity such as browser 170 and the security architecture while encryption with a public key of an 
authentication serv.ce is performed within the security architecture, e.g., at logm component 120. In other 
configurations, encryption with a public key of an authentication service may be performed at the chent entity. 

If the encrypted login credentials provided to an authentication serv.ce are determined to be authentic 
session credentials are issued. In the implementation of FIG. 4, session credentials are embod.ed m a form 
such as exemplary session credentia.s structure 420. Encrypted and clear text portions (421 and 422) of 
sesston credentia.s structure 420 allow contents of the sess.on credential to be read by anyone and changed by 
no one (except the authentication service possessing a pnva.e key). Contents of encrypted portion 421 
correspond to that clear text portion 422 but are encrypted using the pnvate key of the authentication serv.ce 
(e g., of authentication component 130). Of note, principal ids, authorizations and other contents encoded in 
the S ess.on credential may be read by components of the security architecture, and in some embodunents by 
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components external to the secunty architecture. Such components can verify the authenticity of information 
stored ,n clear text pon.on 422 us.ng encrypted port.on 421 and a public key corresponding to the pnvate key 
of the authent.cat.on serv.ce. Of note, the information contained in a session credential is generally not 
sens.t.ve. What is sensitive ,s the state of the infoonat.on. Therefore, secunty arch.tectures employurg 
fac.ht.es described herein ensure that information conta.ned in the sess.on credential ,s provably constant once 
set by an authenticate serv.ce. By using the public key of the authentication serv.ce, wh.ch will in general 
be freely available, together with the encrypted mformat.on, any application can read the information (e g in 
free text) and ascertain that the session credential was created by the authentication serv.ce and that the session 
credent.al has not been tampered w.th. Assuming that the authent.cat.on serv.ce's pr.vate key has no. been 
compromised, tamper.ng w.th the sess.on credent.a! will result ,n a decryption fa.lure. 

In an alternate .mp.ementac.on (no, shown), sess.on credent.als may be digitally s.gned and venf.ed 
by a pubhc key correspondmg to a private key. In such an alternate .mplementat.on, the dig.tal signature 
also allows contents of the sess.on credential to be read by anyone and changed by no one For some 
configurations, the .mplementat.on of FIG. 4 is preferred because encrypted port.on 421 can be used as an 
externally supplied session token. Such a session token representat.on is a compact representat.on of the 
sess.on credential part.cularly approbate for encod.ng as a cook.e placed at a browser and returned with 
subsequent access requests. 

Referring aga.n ,o sess.on credent.als structure 420, a sess.on id, a pr.nc.pal id, a trust level, group 
ids, a creat.on t.me and an exp.rat.on tune are encoded in both in encrypted port.on 421 and clear text port.on 
422. The sess.on id is a un.que identifier for a pers.stent session maintained by the secunty architecture In 
.mplementat.ons .n which credent.al upgrade is prov.ded or in wh.ch a session credential expiration and 
refresh .s provided, multiple successively issued sess.on credential mstances may encode the same session id 
and correspond to the same pers.stent sess.on. Principal id encodes an identifier for a principal to which the 
secunty architecture has resolved login credentials. For example, a login credential including a usemame jdoe 
and a password corresponding to jdoe may be reso.ved by the secunty architecture to a unique principal id 
assocated with John. Q. Doe of the sh.pp.ng and receiv^g department, having an employee badge number of 
12345, etc. 

In some embodiments, a trust level encodes the authorization level to wh.ch a pnncipal has been 
authenticated. In such embod.ments, the encoded trust level serves as a bas.s for evaluating whether a 
principal assocated with the session credentials has been authent.cated to a sufficient level for access to a 
requested resource. For example, a trust level of 5 may be sufficient for access to mformation resources 
having a trust level requirement of 5 or less. Trust levels offer an attractive decoupling of authonzation levels 
and authentication methods as described elsewhere hereu, However, in some embodiments, an authonzation 
encodmg may establish that a pnnc.pal has been authent.cated using a particular authentication mechan.sm In 
e.ther case, an authonzation (e.g., encoded as a trust level) in a cryptograph.cally secured session credential 
allows the secunty architecture to authonze accesses based on prior authentication of a log.n credential and 
without involvement of the authentication service. 
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Group ids can be used ,o gran, or Urn., a u,h„ n2 a,,o„ scope based on group membersh.p TypicaUy 
sess.on creden.ials serve as ev.dence of p„„r authenhcabon and au.horuarton for rn„,hp,e accesses ,o ' 
■nfornrahon resources condoUed by ,he secun* archi.ech.re. However, sess.on credendals may be rep.aced 
on a ,o g ,n credential upgrade as described e.sewbere herein. b addidon, session credenbals of limited 
.empora, val.d.r, m ay be refreshed by period.c replacemen,. b, dte conf.gura.ion of session crede„,i a ,s 
~4* creauon ,,me and exp.radon time aUow , h e securrry archdecrure ,o unprove resrsrance ro repla y 

less, and „„der,y,„ g ,„g,„ credenbals wil, be ,ea u ,hc„„ca,ed pr.or ,„ expira.ion of the sess.on credentia, 
Assum.ng , ha , , he „ nd „, yi „ g , og ,„ credcn „ als wh , ch ^ siored undjr ^ 

componen, .30, rema.n val.d, au.henhcadon component ,30 win .ssue a replacement cryptograph.cally 
secured s.ss,o„ credent,,, (e.g., as sess.on crede„„ al s structure 420,. Depeudmg on men curren, bus, ,eve, 

ZTTb " COnfi8Ur ""°" S ' ***** °" «"» «™ — P— , .he aubWat.on 

ccord d by r e secunry arcbi.ecbrre and encoded as . mas, ,eve, may dlffer from ,b a , encoded ,„ me session 
credenna, replaced. ,f a p™c, pa , , d „, log m credent,,, Has been revoked, reauthent.cat.on may f a „ a„ d . user 
may be prompred ■„ supply a sufficient ,„g,„ credeo,i al s as descr.bed elsewhere herein. Session id and 
pnnc.pa, ,d w,„ ^,ca„y rema.n ,he same for success.ve session crede„,, als associa.ed wi.h a smg.e pers.s.en, 
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.n.erac, w,th enterprise applications and/„, resources and me secnnby archuecrure as descbed herein 
Furthermore, a vartery of information resource ,de„,if,ca,,o„ schemes, such as by Uniform Resource Locamr 
URL,, resource address, ,de„,,f,r or namespace des.gnadon, maybe emp,o y ed. However, for purposes of 
. lusbatton and no, l.m.tabon, ,„ exemp.ary m.eracton .nvolvurg . browser and informah.n resources 
.denttfi^ by URL is described ,„ de, a „. Honethe.es, b a sed on me descnption here., person, of ordrnar, 
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whteh non-browser chenis. au.oma.ed agen. or other systems m K , a c, widr emerpr.se apphca.ions and/or 
resources a „d me secunry archnecrure usmg any of a varrery of mfo ma ,i„„ resource idendficabon schemes. 

Focusmg ,he„ on an exempt browser-^pe cl.cn, c„,,vy, browse, , 70 re qU es,s access ,„ one o, 
more of en.cn.r.se apphcabons and/or resources (e.g.. informahon resource „,)by prescnnng an URX to 
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gatekeeper/entry handler component 110, wh.ch acts as a point of entry for client entiries requiring access to 
applications and/or resources controlled by the security architecture. Gatekeeper/entry handler component 1 10 
rece.ves the request as a proxy for the requested resource. In some configurations, a combtned 
gatekeeper/entry hand.er urstance ,s prov.ded, while in others, separate and/or multiple tnstances are prov.ded 
w.th funcnonally .dentical tnterfaces to other components of the secunty architecture. In some configurations 
multiple mstances of entry handler functionality (e.g., interception of inbound requests and collection of 
env lr onment information) are provided. For example, one or more mstances for each of several connection 
types (e.g., dialup, WAN, etc.) may be employed. One or more mstances of gatekeeper functionality (e g 
a.lowmg access for authorized requests and otherw tS e denymg or initiating appropnate responsive action) may 
also be prov.ded. Configurat.ons and functional decompositions suitable to a particular envrronment and 
expected load requirements will be appreciated by persons of ordinary skill in the art. 

Entry handler functionality (e.g., in gatekeeper/entry hand.er component 1 10) ascertains much of the 
requesting client's environment information. For example, for dial-up connections, environment information 
such as hne speed and low-level line encryption are ascertained. Additional information, such as source 
number (e.g., from caller id information or based on a callback configuration), signaling type ( e g PO TS or 
digital ISDN), etc., may also be obtained. For nerwork connections, similar environment information (e g 
source nerwork and/or node, Virrual Private Network (VPN) low-leve. encryption, etc.) may be obtained from 
mcommg requests themselves or based on a particular entry point (e.g., a particular router or port) More 
generally, gatekeeper/entry handler component 1.0 obtains and/or maintains information such as connect 
location (if ascertainable), temporal information such as request time/date, session start time/date etc 
(preferably m both the client entity's frame of reference and the secun ty architecture or requested information 
resource's frame of reference, if location is ascertainable), and chent type and/or capabilities (e.g., browser 
type and Java Development Kit (JDK) level). In some configurations, information on line speed origination 
point (e.g., mside or outside of a corporate network), browser type, encryption capab.lity, number of hops 
latency, system type, etc. may be gathered. Such tnformation is used in some configurations for mapping 
particular authentication mechantsms to trust levels and for authorization decisions. Env.ronment information 
•s generally packaged into a data structure that is associated with a client session. Other components of the 
secunty architecture may add additional client env.ronment information, such as authentication strength or 
current trust level. 

Gatekeeper functionality (e.g., in gatekeeper/entry handler component 110) checks whether a session 
is already associated with the incoming request. Although other techniques are possible, in some 
conf.gurat.ons in accordance with the present invention, gatekeeper/entry handler component 1 10 checks for 
the presence of a session token in the incoming request. Use of session tokens is described in greater detail 
below; however, in short, a session token may be any data supplied to the client entity for use in uniquely 
•denttfymg an associated session. In general, preferred session token implementations are cryptograph.cally 
secured and mc.ude facil.ties, such as expiration or mapping to a particular connection, to hm.t risk of replay 
attack and/or spoofing. Some sess.on token implementations may encode session, principal, and/or trust level 
tnformation. Some sess.on token .mplementat.ons may employ cook.es, URL encoding, or other similar 
techniques for binding to incoming requests. 
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In some configurations, session tokens are employed to facilitate session continuity and to allow the 
security architecture to associate prior authentication of login credentials with an incoming access request. In 
one utilization, session tokens are issued to client entities as part of an interaction with the security architecture 
and are thereafter presented with access requests. In some configurations, new session tokens (each 
corresponding to a single session) are issued to client entity on each credential level change. In other 
configurations, a session token may remain the same even as credential levels are changed. Session continuity 
means the maintenance of coherent session state across one or more interactions between an entity and an 
information environment. 

Components of session state (e.g., in some configurations, principal id, session id, authenticated trust 
level, group ids and/or roles, creation time, expirat.on time, etc.) are maintained or advanced throughout the 
duration of a session. Typically, aspects of session state are represented internally by the security architecture 
and a session token (e.g., a session id encoded in a cryptographically secured session token) allows the security 
architecture to reference into the internal representation. However, in some configurations, at least some 
aspects of session state may be represented or duplicated in the sess.on token. For example, a principal id and 
current trust level are encoded in one realization of a cryptographically secured session credential and 
associated session token or cookie. In general, a variety of facilities, such as cookies, can be used to maintain 
state across a series of protocol interactions, such as HTTP transactions, that do not otherw.se support 
persistent session state. 

Referring again to FIG. 1, if a session token is present in the incoming request, gatekeeper/entry 
handler component 110 resolves the token to a sess.on object. Alternatively, if no session token is present or if 
a session token is invalid, gatekeeper/entry handler component 1 10 establishes a new session (2). In an 
exemplary configuration in accordance with FIG. 1. session management component 160 allocates a new 
session and supplies associated default session credentials (2) based on the requested information resource and 
environment information. Note that a session is created irrespective of authentication status or identity, 
although some implementations may refuse to even allocate a session based on particular information resource 
requests and/or environment information. Given a session object, which may be resolved from a received 
session token or newly allocated, gatekeeper/entry handler component 110 interacts (3, 4) with authorization 
component 140 to determine whether the requested access is authorized. For some requested accesses and 
security policies (e.g., anonymous ftp access to certain archives), even a session without authenticated login 
credentials (trust level=0) may be authorized. For others, a more substantial trust level may be required. 

Gatekeeper/entry handler component 1 10 supplies authorization component 140 with an identifier for 
the requested resource (e.g., the requested URL) and an identifier for the associated session. Preferably, the 
associated session identifier is cryptographically secured (e.g., as'a signed session credential). In some 
configurations, the signed session credential is obtained from the corresponding session object. In the case of 
a pre-existing session, the signed session credential may be obtained using a received session token. In any 
case, authorization component 140 receives (3) the requested resource and session identifiers and responds (4) 
in accordance with the trust level requirement of the requested resource. In configurations for which 
sensitivity to a changing environment is desired, environment information may also be supplied to 
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authorization component 140. In an exemplary configurat.on, authorization component 140 responds with an 
ALLOW, REDIRECT, or REFUSE response based on the sufficiency of a current trust level. In some 
configurations, authonzation component 140 dynamically calculates a current trust level based on the signed 
session credentials and environment information. In others, authorization component 140 may base its 
ALLOW. REDIRECT, or REFUSE response on a "current" trust level prev.ous.y associated with the signed 
session credentials. Generally, an access request with suffic.ent current trust level is ALLOWED and 
forwarded (14) without further authentication. An authonzation request without proper parameters (e.g., 
without a specified information resource or without a properly secured session credent.al) may be REFUSED. 
Authorization requests associated with a client entity that has been blacklisted or for a resource for which the 
associated client entity cannot be authenticated using any available method to achieve the required trust level 
may also be REFUSED. For example, a g.ven security policy and associated trust level mapp.ngs may dictate 
a REFUSE response in response to an access request to a sensitive resource (such as financial data) by any 
cl.ent entity (even a browser supplying the digital certificate for the CFO, and therefore presumably operating 
on behalf of the CEO) if the access request is received over a dial-up line and originates from an unknown 
number or is received outside of working hours. 

In general, there is an implicit, base level of environment inherent in an authenticated trust level; 
however, m some configurations, a particular authorisation transaction may dig deeper into environment 
information before responding. For example, in configurations prov.ding log-up capabilit.es, an authorization 
service will typically redirect to a login serv.ee if the trust level associated with current sess.on credent.als is 
insufficient for a requested access. However, for sensitive applications in such a configuration, an inadequate 
trust level may result in a REFUSED message rather than a log-up REDIRECT depending on the part.cular 
security policy implemented. 

A REDIRECT response is used to forward the access request to login component 120 so that 
sufficient login credentials may be obtained and authenticated to achieve the required trust level for the 
requested access. Note that in some configurations, both initial login credential^ and credential upgrade are 
provided using the REDIRECT facility. In response to a REDIRECT response (4), gatekeeper/entry handler 
component 110 redirects (5) browser 170 to login component 120. In one configuration, gatekeeper/entry 
handler component 110 issues a client-side redirect via HTTP locat.on directive to forward the request to login 
component 120. Parameters such as required trust level, requested URL and credential passing method can be 
encoded in the redirect URL and supplied (6) by browser 170 to login component 120. Alternatively, some 
parameters can be passed (5A) directly (e.g., through a HttpSession object) although a stateless configurarion 
is prefened. 

A session token is passed to browser 170 in conjunction with the redirect (5) to login component 120. 
Based on the description herein, persons of ordinary skill in the an will appreciate a number of suitable 
mechanisms for passing the session token, including those based on cookies and URL encoding. Preferably, 
mechanisms employed are based on facilities provided by commercially available browsers (e.g., ,n 
accordance with HTML 3.x, 4.x or other de-facto standards), although customized or plug-in facilities for 
receiving and supplying session token may be employed. In one suitable configuration, the sess.on token is 
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cryptographically secured and encoded in a cookie placed at browser 170 using a set cookie directive 
embedded in the redirect. Other configurations may use a less persistent session identification method, such as 
passmg an identifier or session token in the redirect URL without storage at browser 170. Still other 
configurations may transmit a session token, a session credential, or identifier such as a session handle for 
storage in a medium such as a smart card. In configurations providing credential upgrade, persistent session 
identification methods are generally preferred, even for a not yet authenticated client entity, for consistency of 
approach. Note that although the identity of the client entity may not be authenticated to a sufficient level of 
trust, the redirected request includes a session token that at least identifies the session. Other configurations 
may omit the binding of session tokens to sessions of not yet authenticated client entities, though with some 
increase in complexity of login component 120. 

Browser 170 sends (6) login component 120 a new access request using the URL specified in the 
redirect from gatekeeper/entry handler component 110. In configurations employing cookies as a medium for 
passing session tokens, the new access request will include the cookie and therefore the session token. Note 
that in configurations in which the security architecture controls access to resources in several domains, care 
should be exercised to select a tag or tags for the cookie such that it will be provided through normal operation 
of the browser in subsequent accesses to any of the several domains. Persons of ordinary skill in the art will 
apprectate suitable tagging techniques, including the use of multiple cookies. Login component 120 receives 
the access request and determines an appropriate authentication scheme based on mapping rules that identify 
those authentication schemes which are sufficient to achieve a given trust level. Preferably, the mapping rules 
are a function of environment information. In some configurations, mapping rules are implemented as fuzzy 
sets wherein acceptable authentication schemes are a function of required trust level and environment 
information. In this way, environment affects the set of authentication schemes sufficient to meet a trust level 
requirement. 

Generally, mapping rule logic is typically evaluated before a user is challenged to authenticate. 
Mapping occurs as a function of session environment and particulars of the information resource for which 
access is requested. By evaluating the minimum trust level required by the target of an access request, a 
service (e.g., a login service such as provided by login component 120) derives a list of potential 
authentication methods. The service then checks current session environment against the allowed environment 
states for each potential authentication method to trim the list further. If there is no particular resource for 
which access is being requested (e.g., if a user jumps straight to a sign-on page without requesting an access), 
the service will proceed according to the lowest level of trust available consistent with session environment. 
Other configurations may employ differing default behaviors. 

In some configurations, login component 120 queries (7) authorization component 140 to identify the 
set of authentication schemes that meet or exceed the required trust level given a current environment. In 
other configurations, the mapping is performed by login component 120. In either case, login component 1 20 
supplies (9) information to browser 170 to allow the user to select from the suitable authentication schemes 
and to provide an associated login credential. In some configurations, login component 120 supplies browser 
170 with a login page (e.g., HTML) that prompts the user for an application specific user ID and a choice of 
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auther.ticat.on schemes. Interactions with browser 170 depend on the set of credential types that, if 
authenticated, would be sufficient to meet the trust level requuement for access to the requested resource. For 
example, if more than one type of credent.al would be sufficient, logm component 120 may uiteract.vely allow 
a user to select from amongst the credential types (e.g., usmg any HTML-based dialog). Once a particular 
credential type has been selected, logm component 120 interacts with browser 170 to obtain an instance of the 
logm credential to establish the identity of the browser user. 

Some credential types (e.g., username/password pairs, onetime passwords, enigma challenge, etc) 
may be obtained through an interacts process m which the user suppl.es the login credential^) entry into an 
HTML form browser 170 POSTs form contents back to login component 120. Others (e.g., d.g.tal certificates) 
may be suppl.ed (10) for the cl.ent entity from browser 170, or in some configurations, may be obtained from 
or v.a an agent or certificate authority. A personal d.g.tal certificate (such as those .ssued by Ver.sign™, 
Thwate, Entrust or other certificate authority) may be obtained from a browser 170 usmg an HTTP certificate 
request. Although credent.als may be transacted in a var.ety of ways, credentials are typically obtamed from a 
user. Typ.cally, the obtaining is indirect by asking the user's browser to complete the negot.at.on process. In 
such configurations, certificate-based authenticat.on may be transparent to the user. In some conf.gurat.ons, 
further authent.cation can be performed by usmg mformat.on encoded within the certificate to query a 
certificate authority for current status or a lookup to an authent.cat.on database may be performed for more 
detailed requirements. In an exemplary configuration, the more deta.led information could relate to session 
env.ronment or could force an add.t.onal name/password authent.cation as part of the certificate authent.cation 
chain. In a particular .mplementat.on such faclit.es can be prov.ded by mapping rule encodings that require 
successful authent.cation using multiple authentication methods to ach.eve a given trust level. 

Once login credentials have been obtained by logm component 120, they are suppl.ed (1 1) to 
gatekeeper/entry handler component 1 10 for authent.cation. In configurations in which both gatekeeper/entry 
handler component 1 10 and login component 120 have access to a shared object such as the HttpSession 
object, login credential passing via the shared object is suitable. In other configurations, an HTTP POST may 
be employed. In an exemplary configuration, the particular credential passing method is selected as part of the 
original HTTP redirect (e.g., encoded in the redirect URL) although other configurations need not allow for a 
selection or may employ other facilities for selection of a credential passing method. 

Login component 120 also passes control of the access request back to gatekeeper/entry handler 
component 1 10. In an exemplary configuration, logm component 120 issues a new HTTP request (1 1) 
specifying the originally requested URL, which has been stored in the HttpSession object. As before, 
gatekeeper/entry handler component 1 1 0 receives the request. Gatekeeper/entry handler component 110 
extracts the login credentials from the request or from the HttpSession object and passes (12) the login 
credentials to authentication component 130 for authent.cation. Authenticat.on component 130 authenticates 
the login credential, and if successful, queries (13) identification component 150 to establish a correspondence 
w,th a set of entity descriptors that un.quely identifies the requesting entity. In an exemplary configuration, 
entity descriptor types include: entity id, system id (e.g., name/password), cert.ficate, enigma id, smartcard 
token, name/address, and phone One or more of values may uniquely identify an entity and one or more 
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entity descnptor types may support multiple values (e.g., multiple digital certificates, name/password pairs or 
Phone numbers per identity). Once the requesting entity has been identified (14), session parameters are ' 
updated (15) and sess.on management component 160 suppl.es (16) session credentials. Preferably session 
credentials are digitally-signed or otherwise ^graphically secured and returned (17) .gatekeeper/entry 
handler component 110. 

Gatekeeper/entry handler component 110 again suppl.es (18) authorization component 140 with an 
identifier for the requested resource (e.g., the requested URL) and an identifier for the associated session (e g 
the Signed session credentials, authorization component 140 responds with an ALLOW REDIRECT or 
REFUSE response based on the sufficiency the session credentials (and underlying authentication of login 
credentials) for the nus, ,eve, required Tor the requested access. Log.n credentials should now be sufficient for 
access to the requested resource and an ALLOW response ,s supplied (19) by authorization component 140 
Gatekeeper/entry hand.er component 1,0 proxies the requested access (20, 21) to information resource ,9, 
and streams (22) resu.ts back to login component 120. Login component 120, in turn, streams (23) resu.ts 
back to browser 170 

In some embodiments in accordance with the present mv«,r.„ 

«<-c witn tne present invention, session continuity is facilitated by 
supplying a sess.on token to browser 170. For e Xample in one configuration, login component 120 suppl.es a 
session token us.ng a set cook.e d.rect, ve encoded with the results streamed (23) back to browser 1 70 In 
response, browser 170 stores the cook.e using a tag (typicaUy a fi,ename encoding). Browser 1 70 supplies the 
cookie (and the sess.on token) with subsequent access requests based on a correspondence between the tag and 
the requested resource. Typically, the correspondence .s based on the second-leve, domaui (e.g., sun.com) ,„ 
which the requested resource is hosted, a.though nth-leve, doma.ns or other resource identification and session 
token associating schemes may be employed. In configurations m which the security architecture controls 
access to multiple domains across' which a spanmng single sign-on ,s des.red, multiple cookies may be 
employed. t 

Although the encoding of sess.on ,„ kens usu)g cook „ s .„ pr „ em|y ^ ^ ^ 

factltttes are w.deiy supported and reasonably we,, accepted, other facUi„es may be employed ,„ estabhsh 
sess„„ c„„ tl nu«y. For example, altemafive URL encodings a„d/o, custom or piog-ta sopport for session 
,de„„f,er rece.p,, storage and soppiy may be employed. Also, some configurations may empioy lower-level 
sess.on identifiers, e g, ,s provided by , part.cu.at c„n„ec t io„ type such as mrsted ca„e, id informat.on „, as 
assoctated with , low-leve, ,,ne encryption or virtual pnva.e netwotk infrastructure. As sucb factiioes ate 
lutely to be c„„nec„„„-type specif.c. ., is envtstoned tba, dtey may be used in conjunction with otber session 
.denfifter factfities desctibed above, e.g.. sess.on ,„ k e„s encoded ,„ cookies, .„ one configuration, the u„, qu e 
Ethernet MAC address associated with a network interface card may be empioyed as a sess.on handie The 
MAC address is then used ,„ assoc.a.e wtth a parficuia, se, of session credentials mamtamed by a central 
authonty. In general the represents!,™ ofa sess.on handle can take may forms. 

Refertmg again ,„ P,C. 1, subsequent access requests (e.g., access request , A, mclude , previously 
ass,g„ed sess.on token. As described above, ga.ekeepertentry handler component 110 uses me sess.on token. 
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if provided to resolve a session object containing session credentials, and to determine whether previously 
authenticated credentials are sufficient for the requested access. As described above, authorization compouent 
140 may be queried using session credentials and an identifier for the requested resource to determine 
sufficiency of previously authenticated credentials. In some configurations, sufficiency is determined using 
trust level mappings as described above. Depending on the information resource to which access is requested, 
and in some configurations depending on current session environment information, access request 1 A may or 
may not have associated previously authenticated credentials sufficient to support the requested access. In the 
case of an access request 1 A having a trust level requirement commensurate with previously obtained and 
authenticated credentials (i.e., an access request for which no additional credentials need be obtained via login 
component 120), the access request is proxied (20) and results (21) are streamed directly (23 A) back to 
browser 170. In some configurations, gatekeeper/entry handler component 110 supplies an updated session 
token using a set cookie duective encoded with the results streamed (23A) back to browser 170. An updated 
session token, if supplied, resolves to the same session object as the session token replaced. For example, in 
some configurations, both session tokens encode a same session handle, although other aspects associated with 
session token security such as expiration may be updated. In other configurations, results (21) are streamed 
(23A) back to browser 170 without an updated session token. In such configurations, the previously supplied 
session token remains valid until expired or otherwise invalidated Some variations may employ a session 
token refresh interval. 

Depending on the information resource to which access is requested, previously obtained and 
authenticated login credentials may be insufficient for the trust level requirement associated with requested 
access 1A. As before, authorization component 140 supplies gatekeeper/entry handler component 110 with an 
ALLOW, REDIRECT or REFUSE response based on the trust level accorded based on the previously 
obtained and authenticated login credentials and on the trust level requirement associated with requested 
access 1 A. Advantageously, authorization of individual access requests is streamlined by the encoding of trust 
level in a cryptographically secured session credential or token. In the case of insufficient credentials, a 
REDIRECT response is supplied and gatekeeper/entry handler component 110 again redirects (5) browser 170 
to login component 120. Additional login credentials are obtained as described above with reference to initial 
credentials. Upon successful authentication, access request is proxied (20) and results (21) are streamed (23A) 
back to browser 170. 

Preferably, gatekeeper/entry handier component 110 supplies an updated session token using a set 
cookie directive encoded with the results streamed (23 A) back to browser 170. An updated session token, if 
supplied, resolves to the same session object as the session token replaced. As a result, session state (including 
e.g.. identity mappings, authorizations, roles, permissions, environmental variables, etc.) is maintained through 
the credential level change. However, in the case of a credential upgrade, the session object now encodes a 
login credential successfully authenticated to achieve a higher trust level. In one advantageous configuration, 
the achieved (higher) trust level is encoded in a cryptographically secured session token representation as a 
cookie streamed (23 A) back to browser 170 with results (21). 
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FIG. 2 illustrates operation of an exemplary security architecture providing a single sign-on facility 
with trust level mapping to authentication requirements. As before, an access request is received (201) from a 
client entity. If the request does not contain a session identifier (e.g., a session key or token) or if the request 
can otherwise be reliably associated with a session maintained by the security architecture, a new session is 
created (202). A trust level requirement is determined for access to the requested resource in the context of the 
requesting session environment. In some configurations, as described above, the determination is performed 
by an authorization service such as authorization component 140. Given a trust level requirement, current 
session credentials are evaluated (203) in the context of session environment information to determine whether 
the previously supplied login credentials are sufficient to achieve the required trust level. In one advantageous 
realization of session credentials and tokens, a cryptographically secured encoding of trust level allows 



authorization to be confirmed without invo 



itication service (e.g., with reauthentication of 



login credentials). In the case of a newly created (202) session, the authorization evidenced by session 
credentials will typically be insufficient, although some security policies may allow anonymous access to 
certain n 



For a pre-existing session, i.e., for an access request that can be reliably associated with a persistent 
session by a cryptographically secured session token or otherwise, session credentials may or may not be 
sufficient for access to the currently requested resource For example, after a first access, the identity of an 
entity accessing resources controlled by the security architecture will be authenticated to a trust level sufficient 
for that access. Depending on the trust level requirements of a subsequent access and, in some configurations, 
depending on then current trust level mapping rules and environment information, the level of trust associated 
with a current session (e.g., as evidenced by current session credentials) may or may not be sufficient for the 
subsequent access. In situations for which a current level of trust (e.g., resulting from prior authentication of 
login credentials for an entity associated with the session) is sufficient for later access to the same or to another 
information resource, access is allowed without additional authentication. For example, in some security 
architectures in accordance with the present invention, the security architecture proxies (204) the request to the 
requested information resource and streams (205) a resulting response back to the requesting client entity. 

As described elsewhere herein, sufficiency of current session credentials is determined using mapping 
rules that, in some realizations, include environment information. In general, current session credentials may 
be insufficient (1) because the identity of the requesting client has not yet been authenticated (e.g., in a first 
access situation), (2) because of a higher trust level requirement for the requested access, or (3) because of a 
change in mapping rules or environment that causes a previously sufficient credential no longer be sufficient 
for a particular trust level. Whatever the reason for the insufficiency, a request corresponding to a session and 
client entity that is insufficiently authenticated, and that is therefore not authorized, is passed to a facility for 
obtaining credentials of a type that, if authenticated, will support the required trust level. 

Typically, session credentials and/or an associated session token encode an expiration time (see 
descnption, above, of FIG. 4). In such configurations, a previously sufficient session credential is insufficient 
after its expiration. In some configurations, session credentials are periodically refreshed by reauthentication 
of the underlying login credentials For example, in one implementation, a presented session token indicating 
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expiration in less than five (5) rrunutes causes the security arch.tecture to reauthenticate (not shown) 
underlying login credent.als stored tn a corresponding Sess.onObject (e.g., under the pnvate key of 
authenrication component 130). Reauthentication typically results in a new session credential and associated 
trust level. Depending on then instant mapping rules, the associated trust level may or may no, be sufficient. 
Also, reauthentication may f ai l if the login credentials have been invalidated, revoked or if the login 
credentials have expired. Assuming that reauthenticat.on of logm credent.als ,s successful, updated session 
credentials are .ssued, for example, by authenticate component 130 and supplied (e.g., as a cookie encoded 
session token) to the client entity e.g., browser 170). 

Referring aga.n to FIG. 2, a request corresponding to a session no. authorized for a requested access 
is redirected (206) to a credentia. gathering service (e.g., login component 120). The credential gathering 
service receives (207) the redirected access and obtains (208) a trust level requirement for the requested 
access. In some configurations, the trust level requirement may be passed with the redirected access or 
otherwise associated with the redirected access, in others the trust level requirement may be re-obtained from 
an authorization service such as authorization component 140. A trust level requirement is mapped (209) to a, 
least one authenticate scheme suffic.ent to achieve the requirement based on current trust level mappings 
and, if employed in the mapping rules, based on current environment information Assuming mat a, least one 
authenticat,on scheme is available that, if successful, will support the required trust level, logm credentials of 
that type are obtained (21-0) for the entity and authenticated (211) Some credential types (e.g., 
usemame/password pans, onet.me passwords, en.gma challenge, etc) may be obta.ned through an. interactive 
process in wh.ch a principal (e.g., a human user) supplies the credent,al(s) entry in an HTML form and POSTs 
form contents back to the credential gathenng serv.ee. Others (e.g., certificates) may be obtained for the client 
entity from an agent or authority. For example, a personal d.gital certificate (such as those .ssued by 
VerisignTM, Bwate , EntnJSt or other certlficate ^ ^ ^ ^ ^ ^ ^ 

certificate request. In some configurations, a cho.ee of credential types may be prov.ded and user may select 
from a set of credential types suffic.ent for the requested access. Once appropriate login credentials have been 
obtained and authenticated, the session corresponding to the requested access is updated (213) to reflect the 
new authenticated session credentials. The now sufficiently authonzed request is prox.ed (204) and results are 
streamed back (205) to the requesting client entity. Updated or refreshed session credent.als are typically 
supplied as a session token (e.g., a cookie) encoded with the streamed results . 

FIG. 3 illustrates interact.ons between functional components in an exemplary functional 
decomposition of a security architecture An on-Eine order processtng transaction is exemplary and functional 
boundaries are merely illustrative Based on the description herein, a w.de variety of suitable enterprise 
information environments and functional decompositions in accordance with the appended claims will be 
appreciated by persons of ordinary skill in the art 

In the conf.gurat.on of FIG. 3, apphcat.on and central security portions (321 and 322, respectively) of 
the security architecture are illustrated. Of note, functional components of apphcat.on secunty port.on 321 are 
typically hosed as services on a first server env.ronment, while functional components of central security 
portion 322 are hosted as serv.ccs on a second server env.ronment. In this way, most interactions amongst 



WO 01/1 1452 



PC17US00/20931 



- 19- 



fanctional components occur within a single server environment and do not require network transacts. In 
the configurate of FIG. 3, credentials associated with a calling component (e.g., framework credentials 
associated with application security framework 303 or application credent.als associated with order 
management service 312) are used to establish sufficient authorization for network transactions. Other 
configurations may be employed, however, the relatively small number of network transactions (e.g., 
authenticate transacts 331 and optional value passing transaction 332) tends to improve performance of the 
security architecture. Of note, authentication transaction 331 need only be performed on log.n credential 
authentication (e.g., at initial sign-on or credential upgrade) or reauthenticated (e.g., to refresh session 
credentials). Value passing transaction 332 provides an optional facility for passing values amongst multiple 
components of a distributed application (e.g., a distributed implementat.on of order management serv.ce 312) 
wherein application credent.als are used to med.ate storage and retrieval of values in a central registry. 

User 301 interacts with browser 302 to place an order with order management service 312. An 
application security framework 303 rece.ves an access request including the order and, operating in 
conjunction with a vanety of other serv.ces, prov.des a s.ngle sign-on facility substant.ally as described above. 
If the order does not include a session token or cannot be otherw.se associated with corresponding valid 
session credentials, then sess.on credentials are obtained As illustrated in FIG. 3, session credentials are 
obtained using login credent.als (e.g., a username/password pair, a digital certificate, etc.) Typ.cally, an access 
request without sess.on credent.als will no. have associated login credentials. As a result, and default logon 
credentials (e.g.. .dent.ry=anonymous) are used during init.al phases of a s.ngle s.gn-on process. Nonetheless, 
in some configurations, login credentials may be prov.ded with an init.al access request. More typically, an 
initial access request is received by application secunty framework 303 without session credentials or without 
prior presentation and authentication of login credent.als sufficient to access the requested resource. In 
response to credential gathering operations, a subsequent request is made with login credentials that purport to 
be sufficient, if authenticated, to meet the trust level required for access to order management service 312. In 
such a case, session credentials are obtained by passing login credentials to a central security framework 304. 

Authorization of application security framework 303 for access to components of the central secunty 
portion 322 is checked by query to central authorization serv.ee 306. Assuming that framework credentials 
evidence sufficient authorization, login credentials are authenticated by central authentication service 307 
Central authent.cat.on service 307, in turn, interacts with central principal registry 310 to establish the identity 
and group membership of user 301 and with central session registry 311 to create a persistent sess.on for 
subsequent accesses by user 301 Particulars of the request are logged to central audit service 308 and, if 
authentication was successful, session credentials are returned to application secunty framework 303. 

Signed session credent.als are presented to appl.cation authonzat.on service 313 together with an 
identifier for the requested resource and optionally with an .dentifier for a particular function or facility of the 
requested resource. In response, appl.cat.on authorization service 313 checks the authorization of the principal 
(e.g., of user 301) associated with the session credentials to access the requested resource. Appl.cation 
authorization service 313 interacts with application resource registry 314 to identify trust level requirements 
for the requested resource (and in some configurates, for a particular function or facility of the requested 
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resource) and deterrrunes the sufficiency of a current trust level evidenced by the session credential Note that 
trust level is assessed by inspection of the session credential and without interaction with an authentication 
serv.ee. In some configurations (e.g., as illustrated in FIG. 3), group membership is also evaluated as part of 
the authorization check. 



301 



If the signed session credentials indicate that the requesting entity, e.g., browser 302 on behalf of user 
sufficiently authorized to access order management serv.ee 312, a CreateOrder request is passed to 
order management serv.ee 312 and order processing proceeds in accordance with normal handling thereof 
Additional accesses may be requ.red, e.g., to select delivery options or to confirm some aspect of the order 
Assuming that the additional accesses do not require a higher trust level, they will be passed to order 
management serv.ee 312 based on the correspondence of sess.on credent.als with trust level requirements. 

If an except.on is thrown due to insufficient authorization, e.g., if the signed sess.on credentials do 
not indicate that the requesting entity is sufficiently authorized to access order management service 312 a 
login credential gathering process ,s ,n,t,ated. Based on the required trust level and on rules that encode the 
sufficiency of authentication schemes, a login credential is obtained from user 301 and/or browser 302 The 
obtained login credential is of a type that, if authenticated, is sufficient to meet the trust level requirement for 
access to order management service 312. Aspects of an exemplary credential gathering process are described 
in greater detail above. However, as an example, FIG. 3 illustrates the obtaining of a usemame/password pair 
Once login credential are obtained, they are passed to central security framework 304 (as described above) for 
authentication by centra, authentication serv.ee 307 so that sess.on credentials can be obtained, the requested 
access can be authorized, and the order process.ng .nit.ated. Signed sess.on credentials, typically embodied as 
a eryptograph.cally secured sess.on token that may be stored as a cookie, are passed back to browser 302 with 
results of the requested access. In this way, subsequent access requests are identified as part of a sess.on and 
authorization may be quickly confirmed without unnecessary re-authentication. 

Exempla ry Imp lementation* 

In an exemplary embodiment, at least some of the above-descr.bed components are implemented as 
servlets executable in the context of a commercially-available web server envuonment. For example the 
Java™ Embedded Server (JES) arch|tecture with extensions cert . ficate ^^^^ HyperTex( 

Protocol (HTTP), Simple Network Management Protocol (SNMP), Secure Sockets Layer (SSL) extensible 
Markup Language (XML) grammar processing and secunty Access Control List (ACL) support available from 
Sun Microsystems, Inc. is one suitable environment. Java and all Java-based marks and logos are trademarks 
or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. 

In general, the description herein ,s focused on aspects of a secunty architecture, rather than on 
peculiarities of a particular implementation environment. It is envisioned that secunty architectures in 
accordance w„h the teachings of the present invention may be implemented in the context of many 
commeroally-availab.e networked information service envuonments, including web server environments as 
well as in custom environments and environments that in the future will be developed However, to facilitate 
an understanding of broad concepts using a spee.fic exemplary environment, and without limitation, the 
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description herein may include terminology specific to the Java Embedded Server (JES) arch.tecture. 
Nonetheless, based on this descript.on, persons of ordinary skill in the art will appreciate implementations 
suitable for other environments. The scope of the invention, as defined by the claims that follow, is not limited 
to any specific implementation environment. 

While the invention has been described with reference to various embodiments, it will be understood 
that these embodiments are Ulustrative and that the scope of the invention is not lim.ted to them. Many 
variations, modifications, additions, and improvements are possible. For example, the set of authentication 
schemes descnbed herein is illustrative and embodiments in accordance with the present invention may 
include others, including those that may be hereafter developed. If employed, rules mapping trust levels to 
authentication schemes may be encoded in a variety of ways depending on the particular implementation In 
general, such mapping rules may be encoded as static or dynamic tabie associating trust level to authentication 
schemes. Alternatively, mapping rules may be encoded as predicates or in other declarative forms. Mapping 
ru.es may be encoded m a weighted logic or fuzzy set form. Additionally, particular mappings may depend 
environment information. Furthermore, evaluation of mapping rules may be performed in a vanety of 
functional components such as an authorization serv.ce, a credential gathering serv.ee or a gatekeeper. 
Session cont.nuity may be provided using crypiographically secure session tokens passed as cook.es or by 
other mechanisms. 

In some configurations, a session token ,s a compact encrypted representation of at least selected 
contents of a session credential. Other compact representations corresponding to a session credenrial may be 
employed. Alternatively, the same representation of session credentials may be employed both within the 
security architecture and outside the security architecture (e.g., at a browser or other client). Suitable contents 
of a session credential (and session token, if employed) will be appreciated by persons of ordinary skill in the 
art based on the description herein of specific examples. 

More generally, plural instances may be provided for components described herein as a single 
instance. Finally, boundaries between various components, services, serviets, registries and frameworks are 
somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative 
configurations. Other allocations of functionality are env.s.oned and may fall within the scope of claims that 
follow. Structures and functionality presented as discrete components ,n the exemplary embodiment^) may 
be unplemented as a combined structure or component. These and other variations, modifications, additions 
and improvements may fall within the scope of the invention as defined in the claims that follow. 
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WHAT IS CLAIMED: 

1 A session credential for use in a security architecture controlling access to one or more 
information resources, the session credential comprising: 

a principal identifier uniquely identifying a principal; and 

an encoding of authorization accorded by the secunty architecture after prior authentication of a login 
credential corresponding to the principal, 

the principal identifier and authorization encoding being cryptographically secured and allowing the 
security architecture to evaluate sufficiency of the authorization for access to the one or 
more information resources without re-authenticat.on of the login credentials. 

2. A session credential as in claim I, 

wherein the cryptographic securing includes encrypt.on of at least the principal idennfier and 
authorization encoding using a private key assoc.ated with the security architecture. 

3. A session credential as in claim 1 , further comprising: 
an encrypted portion and an unencrypted portion; 

the unencrypted portion allowing contents of the session credential, including the principal identifier 

and authorization encoding, to be read without possession of a key; 
the encrypted portion being encrypted with a private key associated with the security architecture and 
allowing authenticity of the unencrypted portion to be confirmed using a public key 
i corresponding to the private key. 

4. A session credential as in claim 3, 

wherein the encrypted portion is supplied external to the security architecture as a session token that 
uniquely identifies a corresponding persistent session maintained by the security 
architecture. 

5. A session credential as in claim 4, 

wherein the session token is encoded as a cookie supplied to a browser; and 

wherein the cookie is included with access requests made by the browser targeting the one or more 
information resources. 

6. A session credential as in claim 3, 

wherein the cryptographic securing is by a private key possessed substantially only by an 

authentication component of the security architecture; and 
wherein authenticity of the cryptographically secured principal ident.fier and authorization encoding 

is verifiable by components other than the authentication component using a public key 

corresponding to the private key. 
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7. A session credential as in claim 1, 

wherein the cryptographic securing includes a dig.tal s,gnature encompassing at least the prmapal 
identifier and authorization encod.ng and thereby allows authenticity of the principal 
identifier and authonzation encoding to be confirmed using a public key 

8. A session credential as in claim 1 , further comprising: 
an expiration encoding. 

9. A session credential as in claim 1, further comprising: 
a session identifier. 

10. A session credential as in claim 1, further comprising: 
a group identifier. 

1 1. A session credential as in claim 1, further comprising: 
one or more additional elements selected from 

an expiration encoding; 
a session identifier, and 
a group identifier, 
the one or more additional elements also cryptographically secured. 

12. A session token for transfer between a client entity operating on behalf of a principal and a 
security arch.tecture controlling access to an information resource, the session token comprising: 

a principal identifier uniquely identifying the principal; and 

an indication of authorization level accorded by the security architecture after prior authenticate of 
a login credential corresponding to the principal, 

the principal identifier and authorization level indication being cryptographically secured and 

allowing the security architecture to evaluate sufficiency of the authonzat.on for access to 
the information resource without re-authenricat.on of the login credentials. 

13. A session token as in claim 12, encoded as a cookie stored at a browser. 

14. A session token as in claim 12, placed at a browser in response to a set cookie d.rect.ve by the 
security architecture. 

15. A session token as in claim 12, encoded for transfer to the client ent.ty. 

16. A sess,on token as ,n cla.m 12, encoded ,n a communication medium as informat.on in transit 
between the client entity and the security architecture. 
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17. A session token as in claim 1 2, 

wherein the client entity includes a browser; and 

wherein the session token is embodied as a cookie supplied to the browser by the security architecture 
and included with an access request made by the browser targeting the information resource. 

18. A method of providing authorization verification in a security architecture controlling access to 
one or more information resources, the method comprising: 

obtaining a login credential and authenticating a principal thereby; 

issuing a cryptographically secured session credential encoding at least an identifier for the principal 
and a first authorization accorded based on the authenticating; and 

for plural requests for accesses to the one or more of the information resources, selectively allowing 
access based on sufficiency of the first authorization encoded by the cryptographically 
secured session credential for access to the one or more of the information resources, 
wherein the selective allowing is performed without additional login credential 
authenticating. 

19. A method as in claim 18, further comprising: 

digitally signing the session credential prior to issuance thereof; and 

prior to the selective allowing, verifying authenticity of the principal identifier and first authorization 
encoding using a public key. 

20. A method as in claim 18, further comprising: 

encrypting at least the identifier for the principal and the first authorization using a private key, 
the issued cryptographically secured session credential including at least the identifier for the 

principal and the first authorization in both encrypted and free text form; and 
prior to the selective allowing, verifying authenticity of the principal identifier and first authorization 

encoding using a public key corresponding to the private key. 

2 1 . A method as in claim 20, further comprising: 

supplying the encrypted form of at least the identifier for the principal and the first authorization to a 
client entity external to the security architecture as a session token; 

the client entity presenting the session token with subsequent access requests so that the security 

architecture may perform the selective allowing of the subsequent access requests without 
additional login credential authenticating. 



22 . A method as in claim 2 1 , 

wherein the client entity includes a browser; and 

wherein the session token is encoded as a cookie 
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23. A method as in claim 18, further comprising: 

on an access request for which the first authorization encoded by the cryptographically secured 
session credential is insufficient, 

obtaining a second login credential and authenticating the principal thereby: 
issuing a second cryptographically secured session credential encoding a second 

authorization accorded based on the authenticating by the second login credential; 

and 

select.vely allowing the access request based on sufficiency of the second authorization 
encoded by the second cryptographically secured session credential. 

24. A method as in claim 18, 

wherein the cryptographically secured session credential also encodes an expiration; 
the method further comprising: 

prior to the expiration, reauthenticating the principal by the first login credential; 

issuing a third cryptographically secured session credential encoding a third authorization 

accorded based on the authenticating by the first login credential; and 
selectively allowing subsequent access requests based on sufficiency of the third 

authorization encoded by the third cryptograph.cally secured session credential. 

25. A method as in claim 24, 

wherein the first and third authorizations are equivalent. 

26. A method as in claim 24, 

wherein the first and third authorization are encoded as trust levels that differ in accordance with 

either or both of a changed session environment and changed mappings of credential types to 



27. A method as in claim 1 8, 

wherein the login credential is selected from a set of credential types including one or more of a 

username password pair, digital certificate, an encrypted credentials based on asymmetric, 
symmetric, public, private, or secret key technology, a one-time password, a b.ometnc 
credential based on retinal scan, voice print, or finger print, and a possession based 
credential embodied in a smart card, Enigma card or physical key. 

28. A method as in claim 18, embodied as one or more computer program products including 
functionally descriptive information for directing a processor to perform the login credential obtaining and 
principal authenticating, the cryptographically secured session credential issuing, and the selectively allowing 
access based on sufficiency of the first authorization by the cryptographically secured session credential, the 
one or more computer program products encoded by or transmitted in at least one computer readable medium 
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selected from the set of a disk, tape or other magnetic, optical, or electronic storage med.um and a network, 
wireline, wireless or other communications medium. 

29. An information access control facility comprising: 

an apphcat.on proxy for receiving an access request targeting one of the informat.on resources, 

extracting a cryptographically secured session token from the access request, and selectively 
proxying the access request; 

means response to the applicat.on proxy for evaluating sufficiency of an authorization encoded in 
the cryptographically secured session token for access to the targeted informat.on resource. 

30 An access control facility as in claim 29, further comprising: 

credential gathering means responsive to an .nsuffic.ent zero or more login credentials associated 
with the session, the credential gathering means obtaining a login credential of type 
sufficient, if authenticated, to achieve a trust level requirement of the targeted informat.on; 
and 

authentication means for rece.v.ng the obtained login credential, authenticating a principal thereby 
and issuing a session credential corresponding to the session token. 

3 1 An access control facility as in claim 29, further composing: 

means for transferring the session token between the access control facility and the client entity. 

32. An access control facility as in claim 29, embod.ed as a computer program product encoded by or 
transmitted in at least one computer readable medium selected from the set of a disk, tape or other magnetic, 
optical, or electronic storage medium and a network, wireline, wireless or other communications medium. ' 
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